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Abstract — The SpaceCube™ v2.0 system is a superior high 
performance, reconfigurable, hybrid data processing system 
that can be used in a multitude of applications including those 
that require a radiation hardened and reliable solution. This 
paper provides an overview of the design architecture, 
flexibility, and the advantages of the modular SpaceCube v2.0 
high performance data processing system for space 
applications. 

The current state of the proven SpaceCube technology is based 
on nine years of engineering and operations. Five systems have 
been successfully operated in space starting in 2008 with four 
more to be delivered for launch vehicle integration in 2015. 
The SpaceCube v2.0 system is also baselined as the avionics 
solution for five additional flight projects and is always a top 
consideration as the core avionics for new instruments or 
spacecraft control. 

This paper will highlight how this multipurpose system is 
currently being used to solve design challenges of three 
independent applications. The SpaceCube hardware adapts to 
new system requirements by allowing for application-unique 
interface cards that are utilized by reconfiguring the 
underlying programmable elements on the core processor 
card. We will show how this system is being used to improve 
on a heritage NASA GPS technology, enable a cutting-edge 
LiDAR instrument, and serve as a typical command and data 
handling (C&DH) computer for a space robotics technology 
demonstration. 
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1. Introduction 

SpaceCube is a family of Field Programmable Gate Array 
(FPGA) based on-board science data processing systems 
developed at NASA Goddard Space Flight Center (GSFC) 
[2], The goal of the SpaceCube program is to provide lOx to 
lOOx improvements in on-board computing power while 
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lowering relative power consumption and cost. SpaceCube 
is based on the Xilinx Virtex family of FPGAs, which 
include processor, FPGA and digital signal processing 
(DSP) resources. These processing elements are leveraged 
to produce a hybrid science data processing platform that 
accelerates the execution of algorithms by distributing 
computational functions to the most suitable elements. This 
approach enables the implementation of complex on-board 
functions that were previously limited to ground based 
systems, such as on-board product generation, data 
reduction, calibration, classification, event/feature detection, 
data mining and real-time autonomous operations. 

The system is fully reconfigurable in flight, including data 
parameters, software and FPGA logic, through either ground 
commanding or autonomously in response to detected 
events/features in the instrument data stream. 

A. Background 

The SpaceCube processing system at GSFC was started in 
2006 funded by the Internal Research and Development 
(IRAD) program [4]. NASA recognized the potential of the 
technology and provided the funding needed to increase the 
Technology Readiness Level (TRL) for space flight 
applications. Specifically, the Hubble Space Telescope 
Servicing Mission 4 management team selected the 
SpaceCube as the main avionics for a space shuttle payload 
called Relative Navigation Sensors (RNS) [2, 3, 5, 8, 9]. 

The version of the SpaceCube that was initially developed 
in the 2006-2009 timeframe is known as SpaceCube vl.0. 
Following the success of the RNS mission, a vl.0 system 
was added to an International Space Station experimental 
payload to study long term effects of radiation [2, 3, 7, 10, 
15]. SpaceCube vl.0 is also the main avionics system 
controlling two follow-on International Space Station (ISS) 
experiments for the Department of Defense (DoD) [11]. 
SpaceCube vl.5 was the bridge from vl.0 to v2.0 
technology improvement [12, 15]. SpaceCube Mini is 
based on the v2.0 architecture and fits within a 1U CubeSat 
form factor, but will not be discussed in this paper. 

B. Hybrid Data Processing 

There is a growing need for higher performance processing 
systems for space as instruments/spacecrafts levy tougher 
electrical interfacing and data bandwidth requirements on 
the computing node of the system. In addition, on-board 


1 



processing of the data products, in some cases in real-time, 
is now a common requirement [1]. 

Typical space processing systems generally consist of a 
single radiation hardened processor which deliver less than 
300 DMIPS along with an anti-fuse FPGA element [1]. 
These processors are not good candidates for applications 
that require fast computations of complex algorithms on a 
high bandwidth or large volume data source. Furthermore, 
this type of FPGA supports fixed functionality and cannot 
adapt to changing application requirements. These 
architectures are very hard to design and intrinsically 
expensive to change such that they are portable to multiple 
missions, dynamic functional requirements, or new post 
launch mission objectives or corrections. 

A hybrid computing system that combines multiple 
processors, reconfigurable FPGAs, flexible interface 
options, with a modular architecture is the solution that will 
bridge the gap between today’s avionics requirements and 
yesterday’s typical stand-alone, sequential processing 
architecture. 

2. SpaceCube v2.0 Overview 

The SpaceCube v2.0 processing system is based on an 
extended version of the 3U cPCI standard form factor where 
each card is 190mm x 100mm in size. Unlike SpaceCube 
vl.O which was a stacking architecture, cards can be easily 
swapped in and out of the system. The base system consists 
of a power card, processor card, backplane, and mechanical 
chassis to accommodate two additional cards. The size of 
the four slot chassis is 13x23x27cm 3 and weighs 
approximately 5kg with four cards installed. Typical power 
draw heavily depends on the number of cards and 
complexity and speed of the FPGA designs. The base 
system will draw 15-20W for a moderate application. A full 
system running an advanced application can draw 40W+. 
This system will be qualified for an operating temperature 
range of -25C to +50C and a total ionizing dose of lOOKrad. 

The SpaceCube v2.0 data processing card features two 
back-to-back Xilinx Virtex-5 FPGAs [6], eight memory 
modules (2GB DDR, 8GB NAND Flash, 16MB SRAM, 
128Mb PROM), a monitor FPGA with analog monitoring, 
10/100 Ethernet, configurable interconnect including gigabit 
transceivers. The backplane is designed as point-to-point so 
each I/O card does not require a PCI controller. The entire 
system including details on design methodology, 
architecture, card descriptions, mechanical packaging, and 
analyses is fully described in [1]. 

The v2.0 processor card infrastructure supports on-orbit 
reconfiguration that was proven on the vl.O system on the 
ISS [2, 10]. Referencing Figure 6 in [1], the Aeroflex 
FPGA configures the Xilinx FPGAs with initial 
configuration files that are stored in PROM. 
Reconfiguration is achieved by allowing the Xilinx FPGAs 
to reconfigure each other with design files that are stored in 
Flash. All files are stored in a redundant fashion (e.g. TMR, 


QMR, etc) and the file structure is mirrored in both Flash 
devices. Additional design files can be written to Flash 
while the system is on-orbit. The Aeroflex serves as the 
health monitor of the Xilinx configuration and can trigger a 
rollback to PROM. To mitigate configuration SEUs, the 
Aeroflex or the Xilinxs can perform configuration 
monitoring and scrubbing. The scrubbing occurs at a 
programmable rate or when an error has been detected. The 
architecture allows for a reliable means of controlling the 
Xilinx configuration data. 

The modularity of the SpaceCube v2.0 system allows for 
quick adaptation to changing avionics requirements. A 
modular and reconfigurable system increases the likelihood 
of reuse for different mission applications, or follow-on 
missions, even if interface and computing requirements are 
drastically different. As shown in [3], cost and schedule can 
be reduced by reusing the same basic system for new 
missions. Reuse of hardware architecture greatly reduces the 
amount of up front Non Recurring Engineering (NRE) costs 
and time associated with building a new system with new 
requirements from scratch. 

Sections 3-5 will highlight how this system is being used to 
improve on a heritage NASA GPS technology, enable a 
cutting-edge LiDAR instrument, and serve as a typical 
C&DH computer for a space robotics technology 
demonstration on a relatively accelerate schedule. 

3. LiDAR Instrument 

Goddard’s Reconfigurable Solid-state Scanning LiDAR 
(GRSSLi) is an in-house GSFC technology development 
project pursuing a space flight imaging proximity LiDAR 
with unique capabilities to generate 3 dimensional imagery 
(see Figure 1) at high frame rates for on-orbit autonomous 
rendezvous and docking (AR&D) and extreme measurement 
accuracy for planetary scientific investigation. Utilizing 
advanced high TRL technologies such as 
microelectromechanical systems (MEMS) laser beam 
steering and high performance reconfigurable computing of 
the SpaceCube v2.0, as well as GSFC's deep understanding 
of laser based sensing systems, GRSSLi is pushing the 
boundaries of terrestrial and space flight LiDAR 
technology. 

The GRSSLi system offers two operational modes: high 
speed imaging, and precision measurement. In high speed 
imaging mode, the laser is rastered over the scene firing at a 
200 KHz rep rate. FPGA logic processes reflected laser 
pulses in real time every 5 microseconds producing a 
measurement with 6mm range resolution and down to 
5.6mm noise la. With a 128 x 128 raster scan over 
GRSSLi’s 40° field of view, this equates to 12 Hz images. 
Thus, GRSSLi furnishes comparable frame rates and spatial 
resolutions to flash lidars with measurement quality that is 
10 to 50 times better. In the 40° degree FOV configuration 
our system is sensitive from 1-50 meters. We intend to 
advance our current detector and laser technologies to 
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extend our range up to at least 100 meters without 
sacrificing the wide FOV. 



Figure 1-4 megapixel point cloud of a whiteboard on a 
lab chair acquired by GRSSLi 


In precision measurement mode, GRSSLi averages reflected 
laser pulses within a SpaceCube FPGA at a 3 MHz rate to 
produce high quality range measurements with 0.5mm range 
resolution and 1.3mm noise la every 87 milliseconds. This 
is useful for producing high quality scans of rocks and other 
planetary features during rover based or asteroid exploration 
missions. Additionally, programmable MEMS laser beam 
steering allows the system to track the location of a retro 
reflector with unprecedented accuracy, thus enabling precise 
closed loop positioning of robotic arms improving mission 
efficiency and scientific yield. 

A. Digitizer Card 

The GRSSLi system design necessitates a high speed analog 
to digital converter (ADC) to sample receiver wave forms. 
The chosen converter utilizes 4 x 12 bit low- voltage 
differential signaling (LVDS) buses operating at 400 MHz 
each in addition to various control signals. It was therefore 
determined that the backplane could not support this number 
of IO, and the SpaceCube v2.0 processor card had to be 
modified to include the high speed ADC on the card itself. 
Also to generate the ADC RF clock a mezzanine card was 
added to the digitizer card. 

To accommodate ADC circuitry, 2 DDR chips originally 
connected to the bottom V5 FPGA as well as Ethernet 
circuitry were removed from the original SpaceCube v2.0 
processor card design. The end result is an extremely 
capable 2 Virtex-5 processor board (see Figure 2) that can 
sample 2 differential RF channels at 1.54 GSPS with 12 bit 
resolution and process/interpret the signals in real time. 



Figure 2 - LIDAR High-Speed Digitizer Card 


B. Laser Card 

The GRSSLi system design also requires a high reliability 
3uJ 1550nm 200 KHz rep rate fiber laser. A custom rad- 
hard circuit card was designed and integrated with space 
flight qualified electro-optic components to produce the 
SpaceCube v2.0 compatible laser card pictured in Figure 3. 
It receives a digital pulse from the digitizer card that triggers 
a seed laser which is amplified by an integrated Erbium 
Doped Fiber Amplifier (EDFA). The output of the EDFA is 
sent to the collimator lens pointed at the MEMS mirror, 
which directs the laser out of the optical system and into the 
world. 



Figure 3 - LIDAR Laser Card 


C. Front-End Interface Card 

The Front End Interface Card (FEIC) shown in Figure 4 is a 
custom SpaceCube v2.0 compatible cPCI card for 
interfacing the main GRSSLi SpaceCube box to the Front 
End box as described in the next section. 



Figure 4 - LIDAR Front-End Interface Card 
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D. GRSSLi Front End Box 

The GRSSLi system is separated into two boxes as shown in 
the Figure 5 system diagram. The Main Electronics Box 
(MEB) and the Front End Box (FEB). The MEB contains 
all the SpaceCube v2.0 compatible 3U cards described 
above, whereas the FEB contains a custom rad hard MEMS 
driver card, a Short-Wave Infrared receiver card delivered 
by the Army Research Lab [13], the MEMS mirror, and all 
the necessary optics. 



Figure 5 - GRSSLi System Block Diagram 


F. GRSSLi System 

All of the previously described components have been 
integrated, as shown in Figure 6, and are currently 
undergoing system level functional testing. Linux is 
running on a MicroBlaze processor within the top Virtex-5 
on the Digitizer, and driver code has been developed to 
interface the GRSSLi specific FPGA IP to the software 
system. 



Figure 6 - GRSSLi SpaceCube and Front End Box 


Since the DDR on the bottom FPGA was removed to make 
room for the ADC, we developed a custom PLB bridge that 
facilitates MicroBlaze local bus transactions and DMA’s 
between FPGAs. This effectively extends the system on a 
chip paradigm to system on multiple chips, allowing the 
processor easy access to any number of Xilinx FPGAs and 
facilitating great flexibility when crafting the embedded 
system. 

The end result is a very capable and adaptable space flight 
LiDAR for use in many potential robotic and scientific 
applications. In the future we plan to miniaturize the design 
and combine the two boxes into a single small size, weight, 
and power (SWaP) instrument as well as increase capability 
by enhancing range. 

4. GPS Application 

Goddard’s Navigator is a standalone, high-sensitivity, fast 
acquisition, space-qualified GPS receiver originally 
designed to enable high altitude GPS navigation [14]. 
Navigator is a mission enabling technology for the 
extremely challenging Magnetospheric Multi-Scale Mission 
(MMS) that was launched in March 2015 where it is 
exceeding its required performance, tracking more GPS 
vehicles at greater distances than the baseline mission 
required [17]. It also serves as a critical navigation sensor 
for the Global Precipitation Measurement Mission (GPM) 
that launched in February 2014 and has supported several 
other recent missions (Hubble Space Telescope Service 
Mission 4 [5], Orion MPCV). The Navigator design was 
licensed to Moog Broad Reach Engineering in 2010, and 
they now build a commercial version of it. Recently, the 
Navigator design has been licensed to another company. 


Table 1 - Comparison of FPGA Utilization on Original 
Navigator and Next Generation SpaceCube Navigator 



Track FPGA 
(RTAX2000) 

97% Register Cells 
95% Comb. Cells 
85% RAMs 

Legacy GPS 
Signal 
Processing 
Hardware 

(LI C/A 
Receiver) 

Acquisition 

FPGA 

(RTAX2000) 

80% Register Cells 
90% Comb. Cells 
61% RAMs 

Communications 

FPGA 

(RTAX2000) 

78% Register Cells 
55% Comb. Cells 
35% RAMs 

FFT FPGA 
(RTAX2000) 

61% Register Cells 
88% Comb. Cells 
78% RAMs 

SpaceCube 
2.0 Processor 

Receiver FPGA 

76% Slice Registers 

Card 

(one Virtex 5 

52% DSP Elements 

(LI C/A and 
L2C Receiver) 

FX130) 

31% Block RAMs 
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The original Navigator tracks GPS LI C/A signals, and its 
design uses four Actel RTAX2000 FPGAs and a ColdFire 
microprocessor to implement its signal processing. The 
ColdFire processor and the four Actel FPGAs are fully 
utilized with no room for expansion or modernization (see 
Table 1). The next generation Navigator uses the SpaceCube 
v2.0 as a flight platform. Under GSFC IRAD funding, the 
FPGA logic from the four Actel FPGAs on the original 
Navigator has been retargeted to a single reprogrammable 
Xilinx Virtex 5 FX130T FPGA on the SpaceCube and the 
ColdFire has been replaced by a MicroBlaze soft-core 
processor instantiated in the same FPGA. Modernized GPS 
L2C signal tracking capability has been also implemented 
on the same FPGA. GPS signals are provided to the 
processor by a new RF card, compatible with the 
SpaceCube v2.0 chassis, and described further in the next 
subsection. 


In addition to advancing the capabilities of the original 
Navigator, the SpaceCube platform provides ample 
resources (GPS LI C/A, GPS L2C and the MicroBlaze 
processor require less than one FPGA on the SpaceCube, 
see Table 1) and improvements in SWaP as well as cost. 
The SpaceCube provides a flight-ready platform with room 
for expansion for future applications including processing of 
the other modernized GPS signals (GPS L5 and modernized 
L1C) and signals from other GNSS constellations (Galileo, 
GLONASS, and COMPASS). 


A. Dual Frequency GPS L1/L2 RF Card 

To provide GPS signals to the digital processor, a two- 
chain, dual -frequency, discrete component RF front-end 
card, with 3U (extended) cPCI form-factor, has been 
designed, built, tested and integrated on the SpaceCube v2.0 
platform (see Figure 7). The RF card takes GPS LI and L2 
signals from the GPS antenna and low noise amplifier 
(LNA) and down-coverts these signals through the LI and 
L2 chains, respectively and digitizes the signal and passes it 
to the FPGA for signal processing. 



Figure 7 - Dual Frequency GPS RF Card 


B. Sounding Rocket Demonstration 

The SpaceCube Navigator (Figure 8) will fly on a sounding 
rocket experiment in August 2015. The goal is to 
demonstrate acquisition and tracking of GPS LI C/A and 
L2C signals. The software computes position, velocity and 
time (PVT) solutions based on LI and L2C tracking data 


and transmit telemetry to an external modem via an RS-422 
UART interface at 57600 baud. The FPGA will also store 
raw GPS LI and L2C data samples from the GPS front-end 
on a non-volatile Flash Memory for post-processing on the 
ground. This flight demonstration will increase the TRL of 
the Navigator on the SpaceCube platform and make it 
readily available for future missions. 



Figure 8 - GPS SpaceCube 


C. Future Applications of Navigator on SpaceCube 

This next generation Navigator will target high (> 4 Re) and 
low (< 4 Re) altitude missions in all orbit regimes, where Re 
is the Earth’s radius. Missions already using SpaceCube 
v2.0 for science data processing, for example, requiring a 
GPS receiver will have Navigator as a high-performance, 
low-cost option: simply add the (soon-to-be) flight-proven 
GPS RF front-end card to the chassis, attach an active GPS 
antenna, and load the Navigator software/firmware. 

5. Robotics Application 

The Robotics Refueling Mission (RRM) is a joint effort 
between NASA and the Canadian Space Agency (CSA). 
RRM was launched on STS-135 and installed onto Express 
Logistics Carrier 4 (ELC4) on the ISS 2011 as shown in 
Figure 9. 



Figure 9 - RRM Installation on ISS 
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It is an experiment designed to develop technologies and 
perform demonstrations of satellite servicing tools, 
technologies and techniques that could be used to service 
legacy spacecraft. The use of the on-orbit Special Purpose 
Dexterous Manipulator (SPDM) will be utilized to achieve 
these goals [16]. 

A. RRM Phases 1 and 2 

RRM Phase 1 (RRM1) utilized the SPDM (see example in 
Figure 10) to perform on-orbit demonstrations such as valve 
lockwire cutting, removal of various satellite valve caps, 
fluid transfer through and on-orbit mated valve connection, 
and tape cutting and thermal blanket manipulation. 



Figure 10 - RRM Operations on ISS 


RRM Phase 2 (RRM2) included two new task boards and 
one new tool that are added to the RRM modular structure. 
These new items provide additional capability 
demonstrations. 

There are no centralized avionics computers for RRM1 or 
RRM2. Commanding was performed through the use of the 
discrete command channels on ELC. These channels were 
used to provide a control system for the components of the 
Fluid Transfer subsystem. For telemetry, the avionics 
provided an interface to allow all telemetry taken on the 
payload to be transmitted through the designated telemetry 
inputs on ELC. This system was limited on its command 
and telemetry capabilities due to the fixed number of 
available channels. 

B. RRM Phase 3 

RRM Phase 3 (RRM3) is the latest mission that is scheduled 
to launch in 2017. It will develop the technology required 
to store and transfer liquid cryogens and gaseous xenon on- 
orbit. The RRM3 payload is divided into two modules, the 
Fluid Transfer Module (FTM) and the Tool Stowage 
Module (TSM). The avionics for RRM3 is currently located 
on the FTM. The RRM3 payload FTM is designed to be 
launched in the Dragon Trunk on the SpaceX Falcon 9 
launch vehicle. The payload is compatible with the 
unpressurized environment of the Trunk and is to be 
mounted in the Trunk as Flight Release Attachment 


Mechanism (FRAM) cargo. During operations on the ISS, 
the FTM will be mounted to an ELC, where it is provided 
structural, electrical, and command & data handling 
capabilities. Handling of the payload and its components 
will be done via the ISS (SPDM) Orbital Replacement Unit 
(ORU) Tool Changeout Mechanism (OTCM) interface. The 
RRM3 avionics consists of the Power Distribution Unit 
(PDU), Command & Data Handling (C&DH) subsystem, 
Situational Awareness Cameras (SAC), and the Motor 
Control Electronics (MCE). 

Due to the relatively fast flight schedule, SpaceCube v2.0 
will serve as the C&DH computer for RRM3. The 
SpaceCube v2.0 architecture allows for a quick turnaround 
development flow, compared to typical space systems that 
can have development cycles that can run for 3-5 years just 
for the Engineering Development Unit (EDU), with an 
additional 1 -2 years for a flight unit. 

The C&DH unit is primarily responsible for providing an 
interface for command and telemetry to go between the ELC 
and the payload components. The SpaceCube v2.0 platform 
provides RRM3 with the increased processing capabilities 
required to meet the following requirements: 

Increased command processing and distribution 
Reconfigurable FPGA resources to handle custom 
instrument interfaces 

Data storage for stored commands, command 
scripts, etc., and transfer data to and from onboard 
memory via uplink/downlink communications 
Uplink and downlink using MIL-STD-1553 data 
interface 

High speed downlink using 10BASE-T Ethernet 
data link 

Payload Analog Telemetry Collection 

Multiple subsystem interfaces including RS-422 

and LVDS 

Provisions for future hardware that is added to the 
payload, commanding and telemetry collection 




Compact Thermal 
Imager (CT1) 


Figure 11 - RRM3 Avionics SpaceCube Interconnect 
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Along with the Processor, Power, and Backplane Cards, the 
RRM3 C&DH will have an additional two cards to meet its 
requirements. The block diagram of the SpaceCube avionics 
for RRM3 is shown in Figure 1 1 . 

C. RRM3 SpaceCube Analog Card 

The Analog Card is the third card in the C&DH subsystem. 
The card is responsible for collecting the payload 
housekeeping data: thermal telemetry, internal health & 
status telemetry. The Analog Card data acquisition system 
is used to process multiple analog and digital telemetry 
channels from temperature sensors, pressure transducers, 
liquid/valve sensors, latch valves, and a flow meter. 

The Analog Card uses multiplexer circuits to provide 
telemetry for all thermal and housekeeping channels. The 
multiplexer output is then sent to an Analog-to-Digital 
Converter, where the signal is digitized. The digitized data 
is then routed to the Processor Card. The Analog Card also 
contains the excitation circuitry required for collecting data, 
i.e. constant current source for temperature sensors. 

D. RRM3 SpaceCube ISS Interface Card 

The ISS Interface Card is the fourth card in the C&DH 
subsystem. It is used as the bridge between the SpaceCube 
Processor Card and the FRAM/ELC. The card is designed 
to interface with the FRAM/ELC to transmit telemetry and 
receive commands. Commands are received from the ELC 
1553 data bus on the Interface Card and then routed to the 
Processor Card for processing and distribution. The 
Interface Card also transmits payload data, including health 
and status, over the MIL-STD-1553 data bus to the 
FRAM/ELC interface. The Interface Card also has an 
Ethernet interface. Operations data is transmitted to the 
FRAM/ELC interface through the higher speed Ethernet 
link. This allows for concurrent downlink transmissions. 
The Interface Card will leverage the SpaceCube vl.O 1553 
and Ethernet circuitry that is currently on ISS [3]. 

The Interface Card is also the bridge between the Processor 
Card and other subsystems within the payload. The 
Interface Card contains the circuitry to communicate with 
all of the subsystems utilizing an RS-422 data interface. 
The signals are routed between the Processor and Interface 
Cards through the Backplane. 

E. RRM3 SpaceCube System Description 

For RRM3, the current Processor Card design uses one of 
the two Xilinx FPGAs. The FPGA is the central 

interface/controller on the card. Some of the main functions 
of the FPGA include embedded microprocessor core, reset 
controller, memory interface controller, software load 
controller, time management and distribution, and 
instrument/tool interface controllers. 

The Flight Software (FSW) is designed to work with the 
FPGA design on the processing and distribution of the 
incoming commands, as well as collecting and transmitting 


all of the telemetry. The FSW and FPGA designs will be 
developed using a pre-existing framework for SpaceCube 
that allows for quick adaptation to the new requirements. 
RRM3 plans to utilize the on-orbit FPGA/FSW 
reconfiguration infrastructure to support new instruments, 
tools, and test modes. 

6. Conclusions 

SpaceCube v2.0 fits the need for a hybrid, reconfigurable, 
modular space processing system. 

We have shown how the modular architecture of the 
SpaceCube v2.0 system has been quickly adapted to meet 
various interface and data processing requirements. We 
have highlighted 3 use cases where cost, schedule, and 
functional requirements were made possible due to superior 
performance of the reconfigurable processor card that is 
designed to interface with custom I/O cards. In addition to 
the power card and processor card, we have built 61/0 cards 
for the system, 5 of which have been discussed herein. 

The SpaceCube v2.0 system has exceptional processing 
capability at relatively low power, invaluable flexibility to 
support on-orbit reconfiguration, mission unique plug-in 
cards, trending serial gigabit interfaces, and is packaged in a 
small form factor. As shown in the GPS case, the 
SpaceCube v2.0 system reduces the SWaP of a system 
compared to that of a traditional system using typical 6U 
flight processors paired with multiple anti-fuse FPGAs. 

The SpaceCube is a proven technology; we have flown five 
missions which have successfully operated 14 commercial 
Xilinx FPGAs for a total of 29 device-years on orbit as of 
May 2015, 17 embedded PowerPCs, and 4 embedded 
MicroBlaze processors in space. 

7. Future Work 

The main near term objective is to increase the TRL-6 
SpaceCube v2.0 system to TRL-7. This will be 
accomplished during environmental qualification testing on 
a dedicated unit. 

The RRM-3 mission interface cards will be designed this 
year. The SpaceCube avionics will be integrated and tested 
along with required FPGA and FSW. 
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